Technote 1159

Data Fork Font Support in Mac OS 8.5

CONTENTS

Where Do Data Fork Fonts Come From?

What's in Mac OS 8.5

What's not in Mac OS 8.5

Compatibility Issues

Summary

Where Do Data Fork Fonts Come From?

TrueType fonts

On Windows, TrueType fonts are stored in data fork files (still in an 'sfnt' data structure) with the file extension ".TTF". In the past, to use these fonts on a Macintosh, a user would need to use a utility (such as FontClerk or TTConverter) to repackage the font into a resource-based suitcase. As of Mac OS 8.5, however, this is no longer necessary.

Windows also supports TrueType Collections, or ".TTC" files, which contain several 'sfnt' font structures organized with a simple directory scheme. This organization allows the individual fonts to share complete tables among each other. These fonts have also not historically been usable on the Macintosh.

OpenType fonts

OpenType fonts represent a new naming and packaging for fonts. Adobe, in conjunction with Microsoft, have defined a data-fork-based, 'sfnt' structured font file to contain PostScript font data. The glyph data itself is stored in a new format called CFF, or Compact Font Format. The notion behind this structure is that these fonts could behave the same as TrueType fonts on that platform. These fonts are also intended to work on the Macintosh.

The primary goals of the data fork font support effort for Macintosh was to support the new OpenType fonts, and to support the Windows TrueType fonts directly.

What's in Mac OS 8.5

Support for data fork font files was added to several layers of MacOS 8.5, with each layer having responsibility for a different aspect of support.

The Finder

The Mac OS 8.5 Finder was enhanced to support identification and autorouting of data fork font files. Two flavors of data fork file are supported; the individual font (.TTF and .OTF files) and collection (.TTC). These are assigned file types 'sfnt' and 'ttcf', respectively, by Internet Config. The file type assignment happens when the fonts are first brought onto the system. When dropped into the System Folder, the Finder will assign appropriate icons to the files and autoroute them to the Fonts folder.

Currently, there is no support for double-clicking a data fork font file. They behave most like the individual TrueType files (as opposed to suitcases) and as such, they cannot be renamed or opened.

The Font Manager cannot make use of any font for which there is no 'FOND' resource. That resource forms the basis for font access and processing. Data fork fonts don't come with 'FOND's and so are not immediately usable by the QuickDraw Font Manager with Mac OS 8.5. A scheme has been devised to connect a 'FOND' to a data fork font, but support for synthesizing an appropriate 'FOND' resource is not currently available in the Mac OS.

The 'FOND' connection scheme involves the creation of one additional resource, the 'afnt' or font alias resource. The Font Manager uses the 'FOND's Font Association Table during the process of choosing from among the available bitmap sizes in a font, or electing to use an outline font while rendering. Within the Font Association Table, each entry contains a size field indicating the bitmap size, with the special value of zero denoting an outline font ('sfnt' resource). The entry's resource ID is then used to access the appropriate type of resource using the Resource Manager.

In Mac OS 8.5, Apple has defined the size (-1) to indicate that an outline font is stored in a data fork. The Font Association Table entry's resource ID is that of a new resource, the 'afnt'. An 'afnt' resource is simply an Alias Record and has the following structure:

Apple currently reserves all of the user bits and has defined the least significant:

1. A value of all zeros for the user bits indicates a simple, single font data fork. The alias data can be passed to the Alias Manager for resolution. The target font is then expected to begin at offset zero in the file.
2. If the least significant byte of the user bitword is 1, then an offset into the data fork file is present following the private alias data in the resource. This is used for targeting a member of a TrueType Collection file. Thus, an 'afnt' resource targets a single font.

A font management utility can activate data for fonts by simply making a 'FOND' and associated 'afnt' resources visible to the Font Manager. The data for files themselves can reside outside the Fonts Folder. When creating the alias that goes in the 'afnt' resource, do not make a "minimal" alias; ideally, it should be an alias relative to the aforementioned temp file (or the suitcase file, it suitcases are created). Keeping the data fork file out of the Fonts Folder also saves on FCBs since the new font system only opens the data fork file when needed. Referencing data forks on network volumes is doable, but risky, especially if the network connection fails in midstream. Data fork files on CD-ROMs can also be targeted using these methods.

In Mac OS 8.5, Apple introduced a new API to support layout and drawing of Unicode text called ATSUI (Apple Text Services for Unicode Imaging). Direct support for data fork fonts resides at the lowest levels of this software. ATSUI is able to make immediate use of data for fonts, since it does not rely on 'FOND' resources. Note that fonts activated using 'afnt's are also picked up by ATSUI. Since many Windows TrueType fonts, and all OpenType fonts, are set up to be used for Unicode exclusively, they're a good fit for use by ATSUI.

What's not in Mac OS 8.5

With the Mac OS 8.5 release, there are a few “features” that are not yet available:

1. As mentioned above, automatic synthesis of a 'FOND' resource is not implemented in the OS, so data fork fonts are not immediately usable by the Font Manager. Third-party font utilities will be able to activate these fonts using the 'afnt' mechanism. Apple expects to add a gestalt selector with a future release of the OS that allows developers to detect whether the system is synthesizing 'FOND's for these fonts (so the utilities can skip that step).
2. A related issue for these fonts is the fact that QuickDraw Text expects to be able to map characters to glyphs using Macintosh character encodings. If a Windows font does not contain a Mac 'cmap' table, no mapping can be accomplished, even if the font is successfully activated. Along with FOND synthesis, the synthesis of Macintosh 'cmap's is intended.
3. The Finder does not let a user peer into data fork font files, and the Get Info feature doesn't say much about them. Apple hopes to revise the Finder in the future so that samples of data fork fonts can be looked at just like the behavior for standalone TrueType fonts. This will hopefully also include support for .TTC (TrueType Collection) files.

Compatibility Issues

Software that tries to obtain the 'sfnt' resource directly may be surprised to find the resource handle field is nil when a data fork font is in use. Code that cannot handle a nil in that spot may have problems. Future support for getting outlines from a data fork file is desired. Code that parses 'FOND' resources may be surprised by finding a negative size in a Font Association Table entry. Such software may consider the resource damaged. Going forward, negative sizes will be reserved for such additions.

Until Macintosh character mapping synthesis is implemented, Unicode-only fonts cannot be used successfully by QuickDraw Text despite successful activation.